Authentication and Authorization Frameworks: OpenID and SAML

Introduction#

Picture the following situation. A person who wants to watch a movie buys a ticket for it. The movie ticket will allow entry to its holder, but it won't contain any information about the said holder except for the movie they're authorized to watch. So, anyone can use the ticket, even if they weren't the rightful owner, because there's no way of verifying the holder's identity. In this example, we assume OAuth 2.0 functions like a movie ticket; it only provides authorization and needs further security methods to implement sufficient authentication.

To tackle this vulnerability, this lesson details the following authentication and authorization frameworks:

• OpenID Connect (OIDC):  It's an authentication framework that typically works alongside OAuth 2.0. It’s an open standard and enables its users to log in to multiple applications or websites with a singular set of credentials, removing the need to keep different information for various sites. It allows user authentication without needing applications or websites to store user data.

• Security Assertion Markup Language (SAML): It’s also an open standard and is typically deployed in enterprises. It's both an authentication and authorization standard that allows users to access numerous applications using a singular set of credentials. Through SAML, entities can both authenticate and authorize information access from different domains in a secure way.

Let's begin by expanding on OpenID Connect.

Note: OpenID Connect largely performs the same operations as OpenID, but does so in a more API-friendly manner. Therefore, in our context, we'll focus on OpenID Connect.

OpenID Connect (OIDC)#

This framework makes authentication seamless for developers across websites and apps without having to manage their passwords, which can lead to security concerns. When OAuth 2.0 is utilized with OIDC, it enhances the overall security and reliability of the process, while also enabling SSO functionality. This eliminates the need for frequent transmission of sensitive user credentials, thereby mitigating the risk of several types of attacks.

Note: OIDC differs from OAuth 2.0 in that the latter is used to protect user resources, whereas the former is used to produce secure sign-in experiences by authenticating who the user is.

The advantages and disadvantages of OIDC are as follows:

SAML 2.0#

Security Assertion Markup Language, or SAML for short, also allows the user to access multiple applications with a singular login by using SSOs. It has both authentication and authorization capabilities in its process of exchanging user data between entities. Its updated version, SAML 2.0 was released in 2005. It’s built on top of the XML format and is widely used in government and enterprise applications. SAML centralizes authentication and authorization to increase security by eliminating the need to store passwords on the application server. Therefore, SAML introduces an identity provider (IDP), which serves as a trusted entity between a client and a service provider.

The working of SAML is shown in the following slides:

The SAML 2.0 process can be condensed into the following steps:

1. The application (service provider) the client wishes to access has a trust relationship with the IDP.

2. A client wishes to access a service provider.

3. Since it isn't authenticated, it’s sent to do so in the IDP. It most commonly authenticates itself by signing in with its credentials.

4. Once authenticated, the IDP generates a SAML assertion

5. The SAML assertion is sent to the client.

6. The client forwards the SAML assertion to the service provider. The service provider receives the SAML assertion and maps it to its own user storage using a defined user identifier, such as an email address. Since there is a trust relationship between the service provider and the IDP, the client is allowed access to the application after the service provider verifies the assertion it received. The same SAML assertion can be forwarded to several service providers that the IDP has a trust relationship with, allowing the client access to multiple applications.

7. Google implements SAML 2.0 to implement its SSOs between its individual applications or resources for both authentication and authorization purposes. It reduces the need for repeated sign-ins, which is particularly useful for an entity such as Google, which has numerous related applications in its possession.

The use of SAML 2.0 increases security by eliminating the transmission of additional credentials. This reduces the chances of identity theft, phishing, and spoofing. SAML also increases the speed of application access because the user doesn't have to type in their details to log in, which in turn reduces administration costs to store credentials in the server. To its detriment, SAML isn't designed for modern application types such as SPAs and mobile applications, so consumers tend to lean toward other frameworks (OAuth 2.0 and OIDC) for these purposes. Implementing SAML in SPAs and mobile applications is possible but will lead to security gaps that'll be difficult to overcome. It's also considered more complex when compared to OAuth 2.0 because its process is more complicated to implement, and the size of the exchanged assertions is significant due to XML's inherent complexity. Another drawback of SAML is that it’s vulnerable to man-in-the-middle attacks because an attacker can intercept the SAML assertion and pretend to be the legitimate user.

SAML is mostly used in large enterprises to implement SSOs in B2B (business-to-business) and B2E (business-to-employees) applications. OAuth and OIDC are gaining popularity in recent years, especially in B2C (business-to-consumer) applications, but SAML is still relevant two decades after its inception.

These three frameworks can be compared in the table below:

In this lesson, we examined two protocols, one that functions on top of OIDC to provide both authentication and authorization, whereas the other provides both on its own. Both are valid options when it comes to API design, and their advantages and disadvantages must be compared when debating which framework to implement in our system. If our API communicates with SPAs and mobile applications, OIDC with OAuth is the best way to implement both authentication and authorization. However, OIDC isn't as widely supported as SAML and we may prefer the latter in those cases where this becomes an issue.